The present invention relates generally to Internet Protocol Security processing and, more particularly, to such processing in networking devices included in Virtual Networks.
IPSec (Internet Protocol Security) is a set of protocols defined by the Internet Engineering Taskforce. IPSec protects IP packets and upper layer protocols during transmission between peer nodes by introducing proof of origin and encryption. IPSec outbound processing, which is done when IP packets are received from a trusted network, uses encryption, encapsulating an IP packet inside an IPsec packet. IPSec inbound processing involves de-encapsulation, which happens at the end of the tunnel, where the original IP packet is decrypted and forwarded to its intended destination. Inbound processing may also involve an anti-replay check. An application of IPSec is in Virtual Private Networks (VPN), which extend a private network across a public network, such as the Internet. A VPN enables a computer or processing device to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security and management policies of the private network.
One of the IPSec protocols used in a VPN is known as “Encapsulating Security Payload” (ESP) and provides confidentiality, data integrity, and data source authentication of IP packets. This requires the insertion of an ESP header after the IP header of an IP packet but in front of the data to be protected. An ESP trailer is inserted after the data to be protected. An ESP packet is identified in the protocol field of the IP header. In order to allow IPSec packets to be properly encapsulated and decapsulated it is necessary to associate security services and a key between the traffic being transmitted and the remote node which is the intended recipient of the traffic. The construct used for this purpose is a “Security Association” (SA). SAs are negotiated between peer nodes (or security gateways for example) using a mechanism known as “Internet Key Exchange” (IKE or IKEv2), and are allocated an identification known as a “Security Parameter Index” (SPI). The appropriate SA is identified to the receiving node by including the corresponding SPI in the ESP header. Details of the existing SAs and the respective SPIs are maintained in a Security Association Database (SAD) that is associated with each IPSec node. The precise way in which IPSec is implemented in a system depends to a large extent upon the security policy of the organization wishing to employ IPSec. For example, the organization may specify end-points (e.g., user terminals) to which IP packets may be sent, or from which they may be received, the particular security levels to be used for encrypting packets, etc. Policy is stored in a Security Policy Database (SPD) which is also associated with each IPSec node. Typically, the SPD is distributed amongst a plurality of entities of the IPSec node. A remote host wishing to participate in a VPN must negotiate at least one pair of SAs (one for sending data and one for receiving data) with a VPN server prior to exchanging user generated traffic with the private network. Negotiation is typically carried out using IKE or IKEv2 in accordance with security policy defined in a Policy Database (PD) held in the server. For each remote host participating in the VPN the server maintains a set of SAs in a Security Association Database (SAD).
Network virtualization technology helps in emulating virtual instances on a single hardware system and has many advantages which include low power consumption and reduced space. A typical virtual network may comprise multiple physical systems and each physical system may emulate multiple virtual machines. Each physical system may be referred to as a compute node. These compute nodes may have the capability of cryptography processing or IPSec functionality processing.
To setup an IP Security (or VPN) to a virtual network, a VPN server is installed, where the VPN server is typically connected between the internet and compute nodes. The compute nodes are located in the trusted network. IPsec applied packets coming from the untrusted network (or internet) are received by the VPN server. VPN server processes received IPSec packets and then may forward ‘plain’ (un-encrypted) IP packets to the compute nodes. Virtual machines which exist inside the compute nodes will receive those plain IP packets. The virtual machines may also generate IP packets destined for an untrusted network (or internet). The VPN server receives the IP packets coming from the trusted network and applies IPSec, and then forwards the IPSec applied packets to the untrusted network.
The above-mentioned approach to IPSec for virtual networks has the following problems however. VPN traffic is passed through one centralized system. IPSec involves cryptographic operations which require a lot of processing power. There can be a performance bottleneck. Traffic between the IPSec gateways and compute nodes is in clear (i.e., plain packets are transmitted and received), thereby risking exposure. There is under-utilization of resources.
Thus it would be advantageous to provide an IPSec processing method that mitigated the above disadvantages.